The way that commercial "certifying authorities" have gone about things thus far is completely antithetical to how business is transacted on the commercial internet. (hint: banks require *two* forms of ID in order to open a bank account, and CAs provide only *one*. How would you solve this problem?)
Also, there's this nice little gem from section 13 of the X.509(2005) recommendation: "The Attribute Authority (AA) and Certification Authority (CA) are logically (and, in many cases, physically) completely independent. The creation and maintenance of "identity" can (and often should) be separated from the PMI [Privilege Management Infrastructure]. Thus the entire PKI, including CAs, may be existing and operational prior to the establishment of the PMI. The CA, although it is the source of authority for identity within its domain, is not automatically the source of authority for privilege. The CA, therefore, will not necessarily itself be an AA and, by logical implication, will not necessarily be responsible for the decision as to what other entities will be able to function as AAs (e.g., by including such a designation in their identity certificates)." So, why is it that CAs -- which are inherently *NOT* the source of authority to act, even as they *ARE* the source of identity -- still include extendedKeyUsage in the certificates they issue? Why is it they're granted the authority to act as privilege managers as to what a particular identity certificate can do? Why is it that CAs -- which have made amazing strides in implementing multiple "classes" of certificates -- never did their part to educate the end-user as to the differences between those classes? Why is it that browsers have never, before EV, presented any certificate class as any different from any other, instead relying solely on the single padlock icon? The currently-predominant design for security -- which has been repeatedly shown not to work -- has been to try to keep the user from having the information necessary to make good security choices. There currently exists only *one* failure mode, which is to display a screen that has a minimum three-click exception workflow and doesn't do anything to help explain every issue that's wrong with the certificate -- because the PSM doesn't have enough information from NSS about what all the problems are. NSS just returns the first failure code, not The Set Of All Applicable Failure Codes. NSS also reports "unknown CA" in the same way that it reports "explicitly distrusted CA", so it creates even more headaches for the support crowd. -Kyle H On Tue, May 18, 2010 at 12:15 PM, Eddy Nigg <eddy_n...@startcom.org> wrote: > On 05/18/2010 09:44 PM, From johnjbarton: >> >> The designer here is asserting a false, one-dimensional design space and >> insisting that users make a choice along this false dimension. > > Actually the user doesn't have to make a choice I think. It's either working > or it doesn't. All the rest is a work-around... > >> As long as your designer views the problem of security as a tradeoff with >> convenience, you are not going to improve security. > > The inconvenience is for the web site operators, not the users. Users should > not and do not have to experience any inconvenience. And why should they? > Really, why? If they do it's probably your fault, not theirs. > >> You will just create higher and more obscure barriers along that one >> dimension, trying to herd users to the other end. They will work around your >> efforts. > > It's not the users which try to work around those efforts, it's a certain > group trying to do that. And they are not average users. > >> >> I do not believe that users should be asked to make choices > > Exactly, neither do I - and I don't see any valid reason why they should. Do > you see one? > >> When the security system UI presents the user with a choice that can >> expose them to security failures and they make a choice that leads to the >> security failure, where is the problem? > > Probably no way to work around an error should be offered. At least that > would make it secure and doesn't ask for a choice. Would you be happy with > that? Either it works or it doesn't - like HTTP Error 404. > > (There is no choice, the page or site doesn't exist, probably SSL errors > should be handled the same way) > >>> I would choose to view the dancing pigs, because the technology is >>> supposed to make that a safe thing for me to do. I would not, however, >>> enter any important credentials after clicking through the cert warning. >>> I would find it hard to explain the reasoning to my grandmother. >> >> >> Exactly my point. The entire cert warning is pointless, because the users >> are faced with choices they cannot assess properly. > > Doesn't that mean the your grandmother will probably not access that site? > >> The better model begins by abandoning the "security-vs-convenience" >> mindset. Security should be about the maximum actually and effective >> security experienced by users. Our reaction to users clicking through the >> cert dialogs and being exposed to attack should be "we failed", not "users >> have poor judgment". > > I think I start to agree with you - so what is it that you are proposing? > > -- > Regards > > Signer: Eddy Nigg, StartCom Ltd. > XMPP: start...@startcom.org > Blog: http://blog.startcom.org/ > Twitter: http://twitter.com/eddy_nigg > > -- > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
