C. D. Rok wrote: > Ram0502 wrote: > >>There are two paradigms: > >>a) An identity exists as a meta-category, and someone or something > ... > > I don't think that the two you list are the only two options. To me > > they read as the two sides of the binary assertions "we can depend on > > perfection from this part of the system." ... > > When you soften (a) to require a high > > probability of accuracy rather than perfection you end up with a > > component you can build on. > > "High probability" is good enough for manual transactions - such as the > credit cards in a store... But when a small level of uncertainty opens a > possibility for *huge* exploits, the confidence level better as high as > possible.
That's exactly it, the greater the potential exposure the greater the need for security. If I'm reading some random blog musing my needs are different than when I am managing my bank account, for the former I don't necessarily have any real worries whereas for the latter I do. If I am enabled to choose between building trust with what may be my bank's website from scratch or start already knowing the identity of the authorized site operator I wouldn't need pause to consider which I prefer. Would anyone? So given a CA who associates their livelyhood with their effectiveness as an identity authenticator I would definitely feel better about trusting them. Knowing that the CA has operating insurance or significant assets helps too (that's kind of like how banks decide who they trust when lending money). So directly to your point - the higher the confidence level the better when dealing with significant exposures and therefor the more rigourous the CA's policies in authentication the better off the relying party is. > > Presenting the site's key fingerprint to the user as a matter of course > seems more and more like something that can not be avoided. That's a basic assumption in PKI - you need to authenticate sites in a way that's reproduceable. The thing that happened was that folks decided they would try to bring more robustness by adding the identification of legal identity to system. I don't believe that putting a string of numbers in front of a user is part of a well thought out approach. As a practical aside consider that a "website" may choose to update their keys for hygenic reasons and may operate in multiple locations. Each instance would have it's own unique keys and certificates and those would change after certifiate or key lifecycle operations (like key update or certificate renewal). This means that if I am a customer of 50 sites in a typical year and they do annual key updates - I'm tracking a lot of data which perhaps you could optimize the software. I suggest that outsourcing that tracking and making your imposition on the user one that is automatic and natural for the user - like recognizing names of companies - may be a better approach as the user much of the complexity is removed from the user and placed on folks who compete in the market. Trust and security are native concepts to people while cryptography is not so if I were developing software that used cryptography to help improve user security I would use natural constructs to present security decisions and hide to the greatest extent possible the underlying science. _______________________________________________ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
