Because you're assuming that everything that occurs in this world exists in a corporate environment, Eddy. That is the environment where CAs flourish, where CAs thrive, where CAs can do what they're best at -- *because all authority and trust trickles down from the corporation, a tool used to help its workers which are acting on its behalf*.
Realistically, there is exactly one reason for third-party scrutiny: any situation which has an interest defined in law as "fiduciary" requires due diligence. Employment contracts, communications (even privileged communications, such as between an attorney and client), money, contract law, etc. This is the reason why X.509 was developed by an international consortium of governments and government contractors. This is why X.509's trust model is the way it is. This is why X.509 doesn't have any mechanism defined for a sovereign end-user to limit the amount of trust placed in any given credential or assertion. This is why X.509 doesn't allow a user to limit the policies that they're willing to accept in certificate path validation. (To be fair, some minimal nod toward this was put into the PKIX profiles, but realistically there's no implementation. In PKIX, an end-user simply does not have a certifying key, period. This means that literally everything that the end-user wishes to do must start with a "CA, may I <blank>?" question, just to get an assignation of authority -- a certificate, linking a key that the user holds to that which the user wishes to do. I don't care who you are, what interests you represent -- in 1996, the US gave up on the Clipper chip and the entire key-escrow debacle, and that was a full-fledged effort with the full, vast weight of the military, the CIA, and every law-enforcement agency (federally- and state-chartered) behind it. Do you really think that I or anyone else am going to be willing to limit our behavior to those things which an entity which isn't even a government is willing to assign authority for? I'm going to go out on a limb and suggest that I'm already well-aware of "corporate CA software which requires minimum effort". I've been following cryptography for a very long time, and I think that my position outside of the structure which has accreted since 1995 (which requires the use and imposition of a 'central identity/authentication model' simply to continue to exist, much less make any money -- and let's face it, everything which has been stated about the reasons for X.509 certificates and EV certificates is simply designed to inspire fear which makes the acceptance of such a central model much more palatable to those who allow the fear to control their decisions) allows me to see the pitfalls in the currently-dominant paradigm. "I suggest to enable users "self-organize their own networks" correctly, mitigating even their own risks!" Oddly, I have thought about this. I have espoused the ability for users to identify themselves -- either via running their own CA (their "self-signed certificates" that you are unhappy with accepting) or via their own out-of-band communication method for authenticating their own certificate thumbprints. Think about what you say, and then think about how all of the Mozilla products which use NSS makes it damnably frustrating to do so. (And since it's as easy to generate a client certificate which is signed by the user's self-signed CA certificate, you can't simply say that you would let any certificate that wasn't signed by itself have something of a pass in the trust evaluation -- it would chain to an unknown root, which would present the same issue as a self-signed root.) If you have some time, I would ask you to look at http://web.mac.com/wolfoftheair/internetpkirethought.txt . My last edit on it was 8/25/2008, according to the file modification time. (you will likely want to view the source, then turn on word-wrapping, since my text editor soft-wraps for me.) This is an attempt to use RFC 3647's CP/CPS framework to allow individual sites and groups the ability to build their own CAs, and perhaps more importantly to describe how to authenticate certificates from disparate providers that the user doesn't necessarily have knowledge of, much less any desire to assign fiduciary status to -- as well as a user-interface suggestion to reduce the stress of dealing with such untrusted identification/authentication to the absolute minimum required to allow the user to make his own access decisions (and to reduce the possibility of mis-sent messages when multiple conversations are open). At this point, I don't know of any PKIX client that actually supports policy evaluation. I'm pretty sure that NSS doesn't, and I'm also pretty sure that OpenSSL doesn't (I can't speak for other open-source projects) -- as well as being pretty sure that none of the closed-source clients I'm aware of support it either. This is where focus needs to be placed, a means of identifying what policies are being used to issue each certificate, as well as a means of policy mapping (NSS could do this by creating a "web policy", an "email policy", and a "software policy", then issuing a cross-certificate to each of its included CAs that maps the individual policy OIDs to the 'master' web/email/software OIDs -- but nobody wants Mozilla to run a CA, sigh). -Kyle H On Sat, Nov 8, 2008 at 8:05 PM, Eddy Nigg <[EMAIL PROTECTED]> wrote: > On 11/08/2008 10:50 PM, Kyle Hamilton: >> >> I would have no problem with changing the chrome when people step >> outside of the assurances that Firefox tries to provide. I /do/ have >> a problem with removing the ability for users to try to self-organize >> their own networks. (The threat model is different, the policies are >> different, and the fact that everyone on this list is talking about >> removing the ability for self-signed roots to be used at all is an >> extremely counterproductive and cartel-supporting view.) >> > > Kyle, why don't you do that the proper way, specially for corporate > networks? Creating a root and distributing the root is the proper way to go, > not some lousy self-signed crap you never ever will verify anyway. > > I'm not against somebody being his own CA - not wanting to depend on others, > but I'm against risking others by their actions. I think by creating your > own root and by distributing it throughout your network and affected > circles, you provide a certain protection level self-signed can't. You may > even issue CRLs. Others which encounter a site without having imported the > root (currently) still can accept the cert. > > There is open source software out there which provide excellent support for > setting up a corporate CA which requires minimum effort. I suggest to enable > users "self-organize their own networks" correctly, mitigating even their > own risks! Think about it... > > > -- > Regards > > Signer: Eddy Nigg, StartCom Ltd. > Jabber: [EMAIL PROTECTED] > Blog: https://blog.startcom.org > _______________________________________________ > 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
