Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month, online, via Jitsi Meet.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] root CA bloat



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.




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org