- From: Alex Kodat <ALEX@sirius.sirius-software.com>
- Date: Sun, 13 Jun 99 21:09:47 EDT
- To: hallam@ai.mit.edu
- Cc: http-wg@hplb.hpl.hp.com
In-Reply-To: Message of Sun, 13 Jun 1999 19:21:13 -0400 from <hallam@ai.mit.> Promise I'll take this thread off-line after this note unless anyone else is at all interested. > Smartcards are not a requirement for PKI. I have installed many PKIs > and very few use smartcards. Yes, but in many situations involving "public"/shared PC's there doesn't seem to be much of an alternative. Walking around with diskettes containing client certificates won't fly at a lot of places even if they are password protected. Not only are the diskettes easily copied, but they'll often sit on networked PC's that have virtually no real security built into them (or at the very least configured). Now the protection of the client certs depends on passwords that are probably easily guessed in many instances. > Actually management of password systems in a large enterprise is far > from easy. > > Management of passwords in a small system is no simpler than > locally issued certificates. Yes, but in either case it's already considered a "solved" problem or at least one that's relatively under control. Password systems are the devil one already knows and the devil one is stuck with anyway while supporting legacy systems. While I'm sure a lot of forward looking companies are using PKI there are a lot more that aren't. I notice the W3C members only archives are password protected (and not even over SSL it seems ?). > Either way, I don't think that the HTTP working group should spend > any more time trying to make passwords work when applications such > as SSH have demonstrated that public key based systems are more > feasible and easier to manage. Mine is not to say what the working group should be working on and once again profound apologies if I've wasted anyone's time on this. I just wanted to point out that since HTTP *does* support password authentication there *seemed* to be a bit of a hole in its support of password change/expiration. I was hoping (and am still hoping) someone would point out how that hole is not there. I also still believe that people will be using centrally stored passwords at least 10 years from now (Y2K programmers now know that 10 years is not such a long time, after all). Assuming I'm not missing anything, my recommendation to our customers would be PKI (though, they'll laugh at me: we have a hospital customer with 10,000 more or less public PC's with twice the number of users), use some change password HTML page technology with all its incumbent problems or use a hacked version of the publicly available Netscape Communicator that supports the sort of headers I had suggested in my first note. I suspect most will go with the second alternative as being the least attractive but requiring the least work and/or money. Less work almost always seems to trump most other considerations. Thanks again for your comments. Alex Kodat Sirius Software Cambridge, MA
Received on Sunday, 13 June 1999 18:40:44 UTC