CFP: PKI research workshop

lynn.wheeler at firstdata.com lynn.wheeler at firstdata.com
Thu Dec 27 10:22:07 EST 2001


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.



<ben at algroup.co.uk> 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 majordomo at wasabisystems.com




More information about the cryptography mailing list