One alternative to monolithic certificate authorities is a web oftrust approach to trustissues. Here's my view of the flaws this model as an alternative toCAs, when used in practice.

First, you haven't actually removed the need to pick trust roots; everyuser has to start their web somewhere, and usually they are going tostart from some well-known root or roots. What you have really doneis made trust roots less subject to detailed scrutiny and criticism,and probably made it less obvious

Here is a thesis that I have been mulling over lately:

One of Python 3's fundamental problems is that it is trying very hardto pretend that Unix is fundamentally a Unicode operating system, sothat Python itself can be Unicode-based while still working on Unix. Theproblem with this is that it is demonstrably false, as seen in the os.listdir() problem ; Unix is fundamentally a'bytecode strings' environment, and attempts to pretend otherwise canrun into problems any time that this pretense runs

My main reaction to recent events is that theyshow how certificate authorities are one of the real practical weaknessesin SSL. All of the theoretical security in the world can be triviallythrown away by shoddy practices on the part of a single trusted certificateauthority, and we've recently seen not one but two such CAs exposed.

The case of the improperly issued mozilla.com certificate is a clear-cut procedural failure, either failing to vet yourresellers or failing to properly vet a signing request or, for thatmatter

Recently, some backups on our new Solaris x86 fileservers started failing with (GNU) tar reportingerrors about:

Warning: Cannot stat: Value too large for defined data type

More alarmingly, even ls on the Solaris fileserver would reportthis (as an error). Fortunately, I remembered a recent discussion on the ZFS mailing list about this, to the effect that if you are usingNFS, it turns out to be possible to create files with 'impossible'timestamps. Inspection showed that this was indeed the