- From: Alexey Feldgendler <alexey@feldgendler.ru>
- Date: Thu, 02 Nov 2006 15:23:30 +0600
On Thu, 02 Nov 2006 14:27:33 +0600, Anders Rundgren <anders.rundgren at telia.com> wrote: >> The purpose of a digital signature is to certify that the data submitted by >> the client were not forged by an attacker. HTTPS with a >> client-side certificate ensures the same. > Digital signatures is as you say just a variation of authentication. The > things that the DS people wants to add are: > > - A "process" that differs from authentication from the user's point of view This is a problem of browser UI design, not of web standards. > - A persistent trace of the authenticated operation. This is what the > signature adds to the picture. HTTPS with client-side certificates have no > connection to content data since it occurs at the transport level. Digital > signatures are created at the application-level in the schemes that Channy > and I talk about. This is a valid argument, though most of the typical applications where custom ActiveX signing objects are used don't need this property -- they just need secure authentication. > But it is a fact that strong authentication is an alternative to digital > signatures but some of use are trying to change that, not only for legal > reasons but for making a difference between "login" and "accept". As I say above, this should be solved at browser UI level. The browsers should make it clear to the user that presenting a client-side certificate to a website is effectively an act of disclosing and proving the user's identity, and that every piece of information he sends to the server (every user action) is non-repudiable. (And, of course, presentation of any client-side certificates to the server should be optional, easily switchable, and obviously indicated.) -- Alexey Feldgendler <alexey at feldgendler.ru> [ICQ: 115226275] http://feldgendler.livejournal.com
Received on Thursday, 2 November 2006 01:23:30 UTC