BLU Discuss list archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss] root CA bloat
- Subject: [Discuss] root CA bloat
- From: invalid at pizzashack.org (Derek Martin)
- Date: Mon, 24 Nov 2014 14:20:35 -0600
- In-reply-to: <54728AD7.6040507@gmail.com>
- References: <546C4823.6060900@gmail.com> <BN3PR0401MB1204BAB10AE6249C54E4E81BDC760@BN3PR0401MB1204.namprd04.prod.outlook.com> <546D7B55.70903@gmail.com> <BN3PR0401MB1204E9F1CF304F6724855281DC760@BN3PR0401MB1204.namprd04.prod.outlook.com> <546FC87F.1090203@gmail.com> <BN3PR0401MB120420D9FF67828E9C5551C4DC750@BN3PR0401MB1204.namprd04.prod.outlook.com> <54727CF6.9000301@gmail.com> <54728AD7.6040507@gmail.com>
On Sun, Nov 23, 2014 at 08:33:11PM -0500, Richard Pieri wrote: > What I don't understand -- and maybe don't want to understand -- is > why you are jumping through hoops to bolt kludges onto X.509 instead > of working to replace X.509 with something that has verifiable trust > baked in. I think the concept of "verifiable trust" is fundamentally flawed. Not to seem too cynical, but I believe it is a truism that you literally can trust no one 100%--not even yourself. Anyone can experience difficulty sufficient to become desperate, and you can't trust desperate people. But, more practically speaking: It is a practical impossibility for you (or your organization) to actually truly authenticate each and every entity with whom you do business on the Internet. The problem is compounded by the needs of business, which include that the solution must be easy and efficient to implement, and must be flexible enough that it still "works" when, at the whim of management, the policies and practices of the business change (e.g. when politics or punitive policy prevents them from continuing to do business with their current certificate authority). I mention the latter because some of the proposed solutions include the idea of maintaining some sort of a catalog of certificates. This penalizes new certificates signed by new authorities, AND requires that you trust the catalog... All it really does is move the problem, not solve it. For very large entities (like a fortune 500 company) there are most likely literally dozens of people who have access to the "canonical authentication token" (in this case, their certificate's private key), ranging from the guy who generates the CSR, to (possibly) the employees of the CA which signs it (if they escrow the private key), to the people who manage the servers on which the certificate ultimately resides, all of which may be different people or entirely different companies, any one of which may use it for their own nefarious purposes, given sufficient motivation (which will of course vary from person to person). Ed previously touched upon the problem of initial trust... Even with PGP, where you can do key signing parties requiring participants to show ID, you still have at least a couple of problems: People you've never met can proffer false identification credentials, and in the case of a corporate entity, the best you can do is to receive the credentials of an agent of the entity, who may or may not be trustworthy. There are likely more, and more subtle problems too. This problem exists at very nearly every level and flavor of authentication: If you don't actually have longstanding knowledge of the person you are attempting to authenticate, you can never really be sure... and sometimes even when you do have longstanding knowledge. It would not be hard for you to find reports of "long cons" where someone gained the trust of another over a period of time, in order to gain access to their money, etc.. It's not quite the same as what we're discussing, but it's a flavor of it. A more relevant example is the Comodo fraud incident. Of course, the risk of any given attack varies greatly depending on what is being protected and the cost of protecting it... So, I think the reason you aren't seeing much clamoring for improvements in the system is that practically speaking, the improvements to be made, when compared to the cost of trying something new (which is very high), are rather minimal. For the entities who matter most (wealthy corporations) it very likely is not remotely worth the practical gains in security... And that's whom you have to convince, since by and large it's them with whom you are conducting business transactions that you (or they) want to protect. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
- Follow-Ups:
- [Discuss] root CA bloat
- From: richard.pieri at gmail.com (Richard Pieri)
- [Discuss] root CA bloat
- References:
- [Discuss] free SSL certs from the EFF
- From: tmetro+blu at gmail.com (Tom Metro)
- [Discuss] free SSL certs from the EFF
- From: blu at nedharvey.com (Edward Ned Harvey (blu))
- [Discuss] free SSL certs from the EFF
- From: tmetro+blu at gmail.com (Tom Metro)
- [Discuss] free SSL certs from the EFF
- From: blu at nedharvey.com (Edward Ned Harvey (blu))
- [Discuss] root CA bloat
- From: tmetro+blu at gmail.com (Tom Metro)
- [Discuss] root CA bloat
- From: blu at nedharvey.com (Edward Ned Harvey (blu))
- [Discuss] root CA bloat
- From: tmetro+blu at gmail.com (Tom Metro)
- [Discuss] root CA bloat
- From: richard.pieri at gmail.com (Richard Pieri)
- [Discuss] free SSL certs from the EFF
- Prev by Date: [Discuss] free SSL certs from the EFF
- Next by Date: [Discuss] root CA bloat
- Previous by thread: [Discuss] root CA bloat
- Next by thread: [Discuss] root CA bloat
- Index(es):