W3C home > Mailing lists > Public > public-usable-authentication@w3.org > February 2008

Re: Public-Key authentication for websites

From: James A. Donald <jamesd@echeque.com>
Date: Sun, 17 Feb 2008 20:37:32 +1000
Message-ID: <47B80E6C.300@echeque.com>
To: "James A. Donald" <jamesd@echeque.com>
CC: Johnathan Nightingale <johnath@mozilla.com>, Christoph Hack <c.hack@gmx.at>, public-usable-authentication@w3.org

I wrote:
 > At present, the only way to use a client X.509 key is
 > for the site administrator to spend considerable time
 > and effort authorizing client keys by hand, which is
 > in practice so laborious it is seldom done, and if
 > done, is done wrong, breaking, rather than ensuring,
 > security.
 >
 > Analogous problems arise in using TLS-SRP, and indeed
 > in any attempt to use more modern and elegant
 > cryptography than shared passwords for client side
 > identification. If we support client side
 > identification by GPG certificates or SRP unshared
 > secrets in the same way we support client side
 > identification using X.509 certificates, we are just
 > as hosed as we are with X.509 certificates.  TLS-GPG
 > will be just as unworkable for client side
 > identifification as TLS-X.509 is.

As someone just pointed out, Microsoft's cardspace is a
good go at making more modern cryptography actually
usable, contradicting my statement that we are hosed
because of our legacy of existing software and
architecture.  However, cardspace is  an effort to
refactor the web, They are not doing cryptography at the
tls-ssl level.  Instead, cryptography is negotiated at
the http level.

So it can be done, but does require architectural
change, refactoring.  Microsoft is moving away from
the layer paradigm that has been the basis of our past
cryptographic efforts.
Received on Sunday, 17 February 2008 10:37:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:15 GMT