W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: W3C XML Digital Signature Object Element Processing Issue

From: Andreas Kuehne <kuehne@trustable.de>
Date: Wed, 15 Dec 2010 11:26:15 +0100 (MET)
Message-Id: <201012151026.oBFAQF5h014419@post.webmailer.de>
To: deepak@infraware.co.kr, public-webapps@w3.org
Hi Deepak,

I guess you came across some of the very common problems of XML signature verification. Do you use a ready-made toolkit ( like Bouncy Castle ) ? I guess you have to dig into the details of reference resolving ...

But I would propose another approach for your scenario :
I'm member of the DSS-X group of OASIS (http://www.oasis-open.org/apps/org/workgroup/dss-x/index.php). We focus on server side processing of signing, timestamping and verification. 
I would see the mobile browser signature verification as a  very useful application of server side verification. If the browser just makes a simple hash of the widget and sends this to the server  together with a link to the widget the server could verify the widget on behalf of the mobile client. This approach would have a impressive list of opportunities :

- complex processing on the server side only.
- exotic algorithms (like ECC) not  required on the mobile device.
- multiple calls to OCSP responder don't need to be made by the mobile client / no (lengthy) CRLs updates required by the (resource limited) client.
- list of trusted root certificates managed centrally.
- intensive use of caching : A central server can cache results of widget verifications for a while and can return the result immediately (as long as the OCSPs are valid) !
- A quick verification result improves the user experience !

If you're interested in this approach we may setup a sample environment.



----- original Nachricht --------

Betreff: W3C XML Digital Signature Object Element Processing Issue
Gesendet: Mi, 15. Dez 2010
Von: deepak

Hello There,
I am writing to you on the behalf of my company Infraware Inc. We are in the business of making Web Runtime and Browsers for Smartphones and other mobile devices. We are based in Seoul, Korea (South). I got your email address from your webpage. Currently me and my team are involved in the development of a Web Runtime and we are facing difficulties in validating the XML Digital signatures. We thought and hope you could help us in this regard.
We are able to successfully verify the <Reference> element in case it is referencing to a URL of an external resource but we are unable to do so if it is pointing to an <Object> identifier within the same document (Same Document URI References). For Example ;- 
<Reference URI="#prop">
    <Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>
   <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<Object Id="prop">
  <SignatureProperties xmlns:dsp="http://www.w3.org/2009/xmldsig-properties">
   <SignatureProperty Id="profile" Target="#DistributorSignature">
    <dsp:Profile URI="http://www.w3.org/ns/widgets-digsig#profile"/>
   <SignatureProperty Id="role" Target="#DistributorSignature">
    <dsp:Role URI="http://www.w3.org/ns/widgets-digsig#role-distributor"/>
   <SignatureProperty Id="identifier" Target="#DistributorSignature">
We performed the transformation based on the Canonicalization algorithm mentioned in the transform element, but digest value that we obtain after applying the digest algorithm does not match to the given digest value. We suspect that we are not able to figure out the content to be digested correctly. Should the content to be canonicalized start from <Object Id = “prop”> and end at </Object> or should it start from <SignatureProperties> and end </SignatureProperties>.
We would really appreciate if you could help us with this problem by giving some explanation about the process.
Thank you for taking time to read this mail.
Best Regards,

  Deepak Tyagi
  Mobile Business Div./ R&D Team 2 
  3,4,8F Bando B/D 48-1 Banpo-dong Seocho-gu,Korea
  T 82 2 6190 7936   F 82 2 535 0478   M 82 10 2642 9623   E deepak@infraware.co.kr   H www.infraware.co.kr 

--- original Nachricht Ende ----

Received on Wednesday, 15 December 2010 10:26:48 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:28 UTC