"Ed Reed" <[EMAIL PROTECTED]> writes: >2) PKI vendors looked at that and must have said - gee, if we can get >$100-$150/yr/user for managing identity around PKI certificates, why >shouldn't we?
Actually it's even better than that, the companies using the managed service are still expected to act as the RA (registration authority) for certs, so they do all the hard work (verifying users, etc etc). Verisign just give them access to a cert-management engine and collect the fees (OK, there's a bit more work to it than that, but still, the Verisign beancounters must be like pigs in clover over it). >3) the standards groups, PKIX in particular, still haven't addressed the cert >life cycle management issues, and neither has the market place, in any >coherent, interoperable fashion That's my perpetual gripe with PKIX, they're frantically busy distracting themselves with interesting (to them) but ultimately pointless and irrelevant additional standardisation of features so obscure that you need 15 pages of diagrams just to explain to users why they might be useful, while ignoring the fact that most people can't use even the most rudimentary parts of what's already there. This is presumably why the IETF finally shut them down, they realised they'd just keep endlessly churning out RFCs until the sun goes out (I'm not sure whether just leaving them alone to do that in perpetuity wouldn't have been the better option). >After some research, it appears to me that there's a tidy little business >possible for someone to break the mold. Can't be done. SPKI tried it, designing an eminently workable PKI (for the task they were trying to solve) and no-one was interested because it wasn't X.509. Certainly if you throw out all the X.500 baggage that we know doesn't work (X.500 DNs, directories, CRLs, etc etc, which is what SPKI did) you can build a very workable, usable, scalable PKI, but OSI digital ancestor-worship requirements say that you're not allowed to do that. >Anyone care to make a go of it? Please, go ahead. I'll stand over here and watch. It's a vicious circle, X.509 doesn't work/doesn't do what people want, but anything that does work isn't X.509 and therefore won't be accepted by the market. SPKI was a heroic effort to break out of the cycle, but despite a lot of work and input from some very clever people, it ultimately failed for that reason. And unlike the OSI experience in the 1980s (which X.509 is a direct repeat of), for PKI there isn't any DARPA-spawned white knight to come in and fix things when it fails. To some extent this is computer darwinism in action. With networking protocols, some alternative to OSI (that is, a relatively functional set of networking protocols) had to evolve at some point, because computers had to communicate somehow. There was intense market pressure to get something that worked, and eventually it was the IP protocol suite. With PKI on the other hand no such pressure exists, since it's pretty much irrelevant for most people. Sure, your marketing folks can come up with all sorts of neat hypothetical scenarios where PKI would make things so much better, but in reality people and companies can do their banking, tax filing, buying and selling, share trading, and every other use that might justify a PKI, perfectly well without it. As a result there's no pressure on the people involved in PKI standardisation to create anything that meets any real-world requirement, allowing them instead to spend their time building great gothic cathedrals of infinite complexity whose sole purpose seems to be to strike awe and terror into the masses. What's left to vendors is a few niche markets, generally the same groups who are still trying to make a go of using X.400 (government departments/the military, a few large corporates, a few banks) who will keep struggling with X.509 for a number of years. That's a pretty small market to peddle your wares into, as companies like Baltimore, Entrust, and a number of other PKI vendors have found out. Peter (who probably now officially qualifies as a PKI curmudgeon). --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]