RE: A PKI Question: PKCS11-> PKCS12

[lynn.wheeler@xxxxxxxxxxxxx]

PKI key operations can be put into two categories .... authentication
(digital signatures) and secrecy/privacy (encryption).

It is reasonable to have a hardware token with a private key that was
generated in the chip and never leaves the chip for use in authentication
applications .... i.e. digital signatures for reliably authenticating an
entity.

Most key escrow and business continuity issues involve privacy, secrecy,
encryption and recovery of information; aka essential corporate assets
protected with encryption could be lost if the access to the encryption key
only existed in a single chip and that chip malfunctioned (a continuous
availability issue with regard to no-single-point-of-failure and redundancy
... for high value assets, frequently not even simple duplicates, but even
higher levels of redundancy and availability).

While it is possible that the same kind of chips and similar public key
technology may be used in the two cases, the actual business processes
(authentication and secrecy/privacy) have different requirements and design
points.

It is possible to define chips/crypto for use in authentication-only
business processes to have requirements that the private key be unique to a
hardware token and never divulged. At the same time, it is also possible
for essentially identical chips/crypto for use in secrecy/privacy business
processes to have requirements that there be no single point of failure
(even down to the hardware token containing a private key) which involving
critical business assets. To meet business continuity and availability
requirments it is possible that private keys involve in encryption for
secrecy/privacy issues be replicated via means like key escrow.

The business requirments are different for the two different scenarios,
even if the technology is otherwise identical.




<hal.lockhart@xxxxxxxxxxxxx> on 11/27/2001 11:59 AM wrote:


Generating a secret on a smartcard and having it never leave the card is a
major security feature to many people. For example, I believe it is
mandated by Identrus for financial transactions. It is certainly a major
motive for using smartcards, since it insures that all copies of the key
are protected, not just one of them. It also insures that an attacker can
not read out the key and use it in some environment where the card is not
present.


On the other hand, many people believe in the benefits of key backup,
particularly in a corporate environment, where the assets being protected
belong to the organization not the individual. Also some folks believe that
a central facility can do a better job of generating unguessable keys than
a smartcard with limited processing power.


There is never any reason to protect certificates, since they are signed
and intended to be public knowledge. They tend to take a lot of precious
space on a smartcard. But, given the lack of a universally deployed
directory infrastructure, it is convenient to have them "with you".



However, trusted root keys (which may be held in a self signed certificate
for processing convenience) must be protected from modification.


Hal