Kerberos vers ssl

As I see it, SSL has two major advantages over Kerberos:

1. It doesn't require an accessible trusted third party;
2. it can be used to establish a secure connection even when one end of the connection doesn't have a "secret" (a.k.a. "key" or "password"). These two advantages make it ideal for secured Web communication and for similar applications where there is a large user base which is not known in advance.

1. Key revocation. If a Verisign certificate issued to a user is compromised and must be revoked, how will all the servers with whom that user interacts know that the certificate is no longer valid? Either revocation certificates have to be circulated to all relevant servers and cached for a long time, or servers have to verify incoming user certificates against a "revocation server." In that case, the revocation server must be a highly available third party, which means you've eliminated one of the two major advantages of SSL over Kerberos. Kerberos principals can be disabled at will on the KDC and will then become unusable as soon as any cached tickets expire, on the order of hours, without any action by servers.
2. Key security. If I'm issued a Verisign certificate, it has to live on my hard disk. Yes, it may be encrypted there such that I have to unlock it with a password before I can use it, but it's still on the hard disk and therefore vulnerable to cracking attacks. On the other hand, I don't need any sort of certificate to authenticate to Kerberos -- all I need is my password, which is in my brain, not on a hard disk.
3. Cost of use. Kerberos doesn't infringe on any patents. Which means that it can be used for free, while SSL users may have to pay.
4. Open standards. Kerberos has been free from the beginning. The standards documenting it are open and have been developed openly from the start. On the other hand, SSL was developed by a company with a commercial interest in ensuring that its standards become THE standard. Let's just say that Netscape is not exactly known for "playing by the rules" when it comes to developing Internet standards.
5. Flexibility. I'm under the impression, although I may be wrong (if so, I hope someone will correct me), that Kerberos is somewhat more flexible than SSL. For example, if I want to add a new authentication technology to Kerberos (e.g., a new kind of SmartCard with its own algorithm), all I have to do is modify my KDC and my ticket-acquiring client to know how to do the new authentication. Then, it can be used to get Kerberos tickets which will look the same as any other Kerberos tickets and will be usable with any Kerberos-capable application. On the other hand, if I want to implement a new authentication technology for SSL, I believe I'd have to get new versions of all my SSL-capable applications.