On Sat, Mar 21, 2009 at 4:32 PM, Eddy Nigg <eddy_n...@startcom.org> wrote: > On 03/22/2009 12:55 AM, Ian G: >> Hmmm, well, many questions abound: why wasn't it done? where was this >> discussed? Why didn't client certs just happen? Why are we still using >> passwords? >> > > Good question....it's because it's so much more convenient and everybody is > doing it...but guess what, some thought leaders and some leading projects > are working on having that changed.
Because the means of configuration isn't easy on the server side. Because it means having to manually put the certs that one wants to allow to authenticate other certs in the server configuration directories. (Note that various versions of TLS allow for sub-CAs to be explicitly named in the ClientCertificateRequest, rather than their roots. I am going to assume that Nelson knows more on this topic than I do, because I've been wrong with which versions allowed for what.) Because the server is hard to configure to do CRLs and/or OCSP. Because the CRL still needs to be fetched, usually as a cron job. Because the server still needs to maintain its own local database of accepted/trusted users. Because there's no guarantee that a Subject will remain the same Subject, so there's no easy way to map a Subject to a local user. Because there's no guarantee that a Subject is the same as another Subject based on CN or any other individual part of a Subject, so there's no easy way to protect privacy using only portions of the Subject. The problem isn't just on the server side, it's not just on the client side, it's also on the CA side. The CA/B forum should have brought Server vendors into the mix, too, to explain their plights. -Kyle H -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
