W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: Re: Issues with XML Dig Sig and XML Canonicalization

From: <kuehne@trustable.de>
Date: Wed, 17 Feb 2010 08:21:23 +0100 (MET)
Message-Id: <201002170721.o1H7LNpd020904@post.webmailer.de>
To: marcosc@opera.com
Cc: public-webapps@w3.org
Hi Marcos,

thanks for your friendly mail ! 

I'll upload the latest client version to sourceforge and post a link to the list. The server version will take some time, we are a bit stuck due to feature overload ...

Btw.: I would like to ask about the verification side of the widgets. If there is a widget with an author and let's say two distributor signatures it will take some time to do the OCSP requests or even worse to do CRL downloads. I would guess especially for mobile clients the widget startup may appear to be slow. 

Our proposal would be to setup a central service to provide verification of widgets. The client will supply the original link to the widget and a hash of the widget. The server will load the widget from the given URL and compare the client-provided hash. Then verify the wigdet, store the result, and return the result to the client.

The server can take advantage of already processed widget verifications, stored OCSP responses and already verified certificate chains. Moreover the administration of trusted root certificates is always easier at one central point.
So for commonly used widgets the verification server will reply within a fraction of a second. This will improve user acceptance !

In the special case of not publicly available widgets the server replies with a return value that requires the client to include the complete widget into the request.

What's your opinion ? Is it worth to setup a test server for this scenario ?

Greetings

Andreas
----- original Nachricht --------

Betreff: Re: Issues with XML Dig Sig and XML Canonicalization
Gesendet: Di, 16. Feb 2010
Von: Marcos Caceres<marcosc@opera.com>

> 
> 
> On 12/02/10 3:54 PM, kuehne@trustable.de wrote:
> > Hi all,
> >
> > our goal in the OASIS DSS group is make the living with DSig as easy as
> possible !
> 
> Nice.
> 
> > That's why we made a spec to easily access a crypto server component by
> webservice and forget about signature standards, algorithms, validity dates
> ...
> >
> > My company build a open sourced server implementation of the DSS spec and
> moreover we implemented the widget signature spec. And to make the
> programmer feel comfortable we added an ant task that takes the jar and
> applies the signature by calling the DSS server. The build process remains
> as usual, the developer can concentrate on wigdet functionality. Moreover
> the certificates are in a save place ( on the server ) and only the
> admnistrator has to care about expiry days. But that's his daily business,
> if there is SSL around.
> 
> Right.
> 
> > Yes, this smells a bit like "the tools will save us", but we are all using
> compilers day in and day out. I don't know how to write a compiler
> nevertheless I use them. So neither compilers nor signing facilities should
> to be a concern for the widget group !
> 
> We build specs so tools can be built.
> 
> > So just use what's there. And XMLDSig is there !
> 
> Right.
> 
> > Btw: We also got the J2SE code signing spec ( jar signing ) implemented. I
> don't think that's much better solution for widgets. It's just strange in
> other ways ...
> 
> It would be great to have your implementation included in the 
> implementation report for this spec. We are hoping to begin creating a 
> test suite soon. Would you be willing to submit results?
> 
> 

--- original Nachricht Ende ----
Received on Wednesday, 17 February 2010 07:21:55 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:37 GMT