Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote:
> Obviously, a transition to public key authentication can't happen
> overnight but we could do it in stages:
> 1) Develop an infrastructure that makes it really easy to manage private
> keys across multiple devices so that enabling a device to authenticate
> itself as '@alice' or '@bob' is really easy.
You know that I sure like this.
> 3) Since the initial support for (2) will be near zero on day 1, also
> develop a kick ass password manager that can be made ubiquitous, does not
> require a subscription, copes with failures like lost devices etc. This
> allows users to transition to using strong passwords that are different
> everywhere.
I thought that keepassx was one such system.
I admit that I tried to use it, but the UI was terrible, and my hand-rolled
solution was just easier, so I never transitioned.
Also keybase.io has "kvstore".
My impression is that the system uses the service only because NAT,
and can otherwise be told to go peer to peer.
I think that this is an xkcd 927 problem.
> Instead what we end up doing every single time is deciding that we can't
> change the legacy infrastructure so we will do a botch job that has to
> work round the constraints of the legacy infrastructure.
Yes, you are right.
Stephen Ferrel did some interesting work on generating and using client keys
in javascript (but not for HTTP level authentication). I think that was
during the JOSE WG. The idea was that at least losing a database of public
keys on the server was way better than a database of password hashes.
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
Attachment:
signature.asc
Description: PGP signature
