Welome to the Internet, here's your private key

[lynn.wheeler at firstdata.com]

ignoring for the moment the question of why certificates would be needed at
all ....

then public/private key technology is currently being used for (at least)
two distinct & different business processes

1) authentication
2) encryption

The business process of human person authentication has some requirements
about impersonation ... leading to a business requirement that only the
person being authenticated should have access to the authentication
material (aka only the specific person can originate an authenticated
transaction). A hardware token that generates the key-pair inside the token
and the private key can never leave the token can satisfy unique person
authentication thru one-factor authentication "something you have". The
person is the only one with their specific token and that token is the only
container for their specific private key.

The business process for encryption can be totally different. The assets
being encrypted may be corporate assets, not the individuals. In the case
of using public/private key in conjunction with encryption of corporate
assets, the business requirements totally change. The corporation has a
valid requirement for recoverying valuable corporate assets under any
condition (failure/loss of token, person leaves the company, etc).

In the person authentication case, the impersonation issue typically is
viewed as outweighing the failure/loss of token issue. In the case of
encryption of corporate assets, the failure/loss of the token issue would
typically outweight any issues of guarenteeing absolutely that the key can
only occur in a single place not knonw by anybody.

The requirement for a private key only existing in a single place under
control of a single person isn't an attribute of the public/private key
technology .... it is an attribute of a specific business process and
associated business requirements related to that business process. However,
there are other business process applications for public/private key
technology than human person authentication which can have somewhat
different requirements.

aads chip strawman .... public/private key hardware token w/o any
certificates
http://www.garlic.com/~lynn/index.html#aads

random refs:
http://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk
Management and Information Security
http://www.garlic.com/~lynn/aadsm9.htm#pkcs12 A PKI Question: PKCS11->
PKCS12
http://www.garlic.com/~lynn/aadsm9.htm#pkcs12b A PKI Question: PKCS11->
PKCS12
http://www.garlic.com/~lynn/aadsm9.htm#pkcs12d A PKI Question: PKCS11->
PKCS12
http://www.garlic.com/~lynn/aadsm10.htm#diskcrypt Looking back ten years:
Another Cypherpunks failure (fwd)
http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
http://www.garlic.com/~lynn/2001j.html#16 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001n.html#54 The demise of compaq
http://www.garlic.com/~lynn/2002.html#7 The demise of compaq




ptrei at rsasecurity.com on 2/4/2002 9:13 am wrote:


One other scheme I've seen, and which, while it doesn't give me
warm fuzzies, seems reasonable, is to issue the
the enduser a smartcard with a keypair on it. The SC generates
the pair onboard, and exports only the public half. The private
half never leaves the SC (there is no function on the card to
export it).

If you trust the above, then the only copy of the private key
is on the SC, despite it having been generated without the
end users participation.

Peter





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