CFP: PKI research workshop

[Arnold G. Reinhold]

It seems to me that a very similar argument can be made regarding the 
need (or lack there of) for a national identity card.  Organizations 
that require biometric identity can simply record that information in 
their own databases. The business most widely cited as needing 
national ID cards, the airlines, already maintain elaborate customer 
databases for their frequent flyer programs. Adding biometrics, with 
mileage points or faster check-in as incentive, would be easy enough. 
Your frequent flyer application would authorize the airline to 
compare your  identifying data with security databases at other 
airlines, credit bureaus, the government, etc.

If photo matching software is unable to validate two photos of you 
from different databases, both would be displayed next time you check 
in. If the clerk decides they match, that would be recorded. If the 
discrepancy is major, you would be taken aside and the matter 
investigated. Over time, the confidence in any individual's record 
would grow as more use is made of it. There is still the problem of 
protecting the database from alteration, but that applies to whatever 
database would be used to issue national ID cards as well.

Even if high speed data lines are not available at all gates, 
reservations are normally made well in advance, so a passenger list 
with biometrics could be prepared overnight and delivered to each 
gate in printed form (for photos) or on a CD-RW.  Last minute 
reservations could be handled by slower data links or the maker would 
simply be subject to a higher level of scrutiny. Passport numbers 
could be requested at the time of an international reservation and 
checked with the issuing government well before flight. Government's 
that don't cooperate would have their citizens subject to additional 
scrutiny. During times of heightened alert, additional cross checking 
can be implemented.

None of this is particularly hard and all the issues of of forged, 
revoked, stolen or cursorily examined ID cards go away. So do the 
issues of abuse where petty officials confiscate your ID card leaving 
you helpless.

Arnold Reinhold


At 8:22 AM -0700 12/27/01, lynn.wheeler at firstdata.com wrote:
>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




---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com