it isn't that you move it to a central authority .... you move it to an authority that typically is already established in association with authorization ... aka in normal business operation, a business relationship is established that typically consists of creating an account record that has various privileges associated with that account/entity. For authentication purposes a public key can be bound to that account and/or set of privileges. This goes on in the world today .... and would continue to regardless of whether x.509 identity certificates were issued or not. given that businesses have to play the registration function for authorization & privileges ... aka normal procedure doesn't allow somebody to walk into a random bank and withdraw funds from a random account ... regardless of who they are ... aka indentity doesn't magically enable a person to withdraw funds from an arbritrary account ... ability to withdraw funds typically is a privilege associated with whether or not some entity is authorized to perform that function for a specific account. As such, the financial institution has to register lots of information for the account ... also registering a public key is consistent with the existing business processes, liability, administrative and management infrastructure.
In effect, large numbers of business processes already exist for registration, administration, and management of authentication information .... and having a certificate in the loop doesn't eliminate those business processes (whether or not I had a certificate .... there still would have to be something registered that some attribute of "me" has authorization to do certain things). Doing business flow and informatioin management optimization just demonstrates that given existing business infrastructures for registration, administration and management which also includes certificates it is usually trivially possible to demonstrate that the actual certificates are redundant, superfulous and extraneous ... aka directly registering the public key and providing direct binding between the authentication process and the authorization process .... eliminating a possibly huge number of extraneous and unnecessary business entities and business processes associated with certificate-based operation. There doesn't have to be any single central authority in a certificateless model. There can be all sorts of authorities for all sorts of infomation .... which could be also hypothesized for a certificate-based certification and authentication model. However, the certificateless exercise typically trivially demonstrates that any certificate-based solution duplicates existing business processes which aren't going to be eliminated. Therefor, it is then possible to demonstrate business optimization where the duplicate (certificate) business processes can be eliminated as extraneous, redundant, and superfulous. <[EMAIL PROTECTED]> on 12/27/2001 7:16 am wrote: As for the "certificateless" model - all this really does is move the binding from something you can carry around with you to something that has to be done by a central authority. It is not clear to me why this is such a marvellous improvement. Unless you happen to want to own the central authority, of course, which, unlike certificates and CAs, is far harder to replicate privately and therefore, presumably, potentially even more profitable than Verisign's cash cow. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]