On 09/30/13 19:31, Thierry Moreau wrote: > Feedback below, > > Guido Witmond wrote: >> On 09/30/13 17:43, Adam Back wrote: >>> Anyway and all that because we are seemingly alergic to using client >>> side >>> keys which kill the password problem dead. >> >> >> Hi Adam, >> >> I wondered about that 'allergy' myself. I have some ideas about that and >> I'm curious to learn about other. >> >> Here are mine: >> >> 1. The long standing belief is that client systems are untrustworthy. >> >> Any malware will go after the client certificates. So without proper >> sandboxing, capability-security and other partitioning mechanisms, the >> user is toast. >> >> The most popular consumer-OS was (is?) also the most leaky. >> Where was The Hurd when we needed it? Why did people fall for Unix when >> Multics was so much better? >> > > no comment
Well, I've one: It's self determination. Decide what *you* do with your computer, not a sysadmin at a server. Notice: We've gone full circle with Faceboogle/Twitstagram.... > >> 2. It's easier to change a password in a database than to talk the user >> through creating an submitting a new pub/priv key pair. >> > > s/easier/more established practice/ > Agreed. If client certificate where the norm, we would have customer support helping people connect old accounts (of which the've lost their private key) to their new private key. >> 3. The crypto-programs were too diffucult to use. Requiring end users to >> make trust decisions about entities they never heard of. Who is Verisign >> and why should I trust them >> > > yes > >> 4. Client certificates from the big CA-peddlers are akin digital >> passports, eliminating all non-repudiation. Ie, a privacy problem. >> > > 4.a) non-repudiation: more from the semantic of "signature" (a lawyer > advice number 1: never sign anything) than from any actual > non-repudiation experience > > 4.b) privacy: yes, indeed > >> 5. Only recently, computers have become powerful enough to encrypt >> everything, all the time. Now we can afford to burn cpu cycles on >> encryption without getting usability to suffer. >> > > I don't think this is a significant factor. > I remember the discussion between prof. Tanenbaum and dropout Torvalds about the benifits of either a microkernel or a mononlitic kernel. The price was 5%, I believe.... I also remember playing with crypto-tools and that price was close to 100%, ie, losing half your computer power to protect against a remote threat. > Adding an analysis of the underlying technology and how a user might > relate to it (in a mental model) -- some clarification of items 2 and 3: > > 6) PKCS#12 format ... It's a shame for the computer industry; it is > deemed to totally confuse the end-user since *any* explanation of > "PKCS#12" is either wrong or totally confusing. > > 7) The logical separation of client public-private-key-pair usage > paradigm from the certification can of worm: lost in oblivion. It doesn't have to be that way. See my experiments [0] > 8) Password continuity spawns user device migration; a private key > object practically can't be migrated (thanks to PKCS#12 format) Passwords are so *last century*. With all the breaches at high profile targets going on and people still *reusing* passwords at disjunct sites. Even suing sites for leaking their shared password.... That's all solved with proper client certificates. And when Firefox Sync can share password, it also can share client certificates and their respective private keys. > Perspective: I'm still working towards a working prototype based on > (A) the client PPKP usage paradigm (Public-Private Key Pair) > (B) the first party certification paradigm (get rid of requesting any > client PKI certificate from any CA) > (C) an end-user enrollment scheme that facilitates (B) (and PPKP usage > migration in some respect) I guess, you and I have the same idea!. What do you think of my proposed solution: [0] Regards, Guido. 0: http://eccentric-authentication.org/blog
signature.asc
Description: OpenPGP digital signature
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
