Note: for index of full report see: http://jya.com/nrcindex.htm

---------



                            H


           Summary of Important Requirements for 
                 A Public Key Infrastructure


   Based on information from a National Institute of Standards
and Technology (NIST) document on public-key
infrastructure,(1) this appendix briefly summarizes the user,
technical, and legal requirements of a federal public-key
infrastructure, as well as other observations obtained through
interviews and the analysis of pertinent standards.

   +    *Ease of Use*. Certificate infrastructures should not
make applications utilizing digital signature capabilities
more difficult to use. To support ease of use, the
infrastructure must provide a uniform way to obtain
certificates in spite of the possible differences in
certificate management policies employed by different segments
of the infrastructure.

   +    *User Authentication*. To ensure proper linkage of a
public key with a specific user, the identity of that user
must be authenticated. User authentication is usually
conducted by the certification authority (CA) during the key
certification process.

   +    *Certification Policies*. If the existence of
different certification policies is allowed, certification
policies for both individual users and organizational users
must be clearly articulated. In addition, mechanisms must be
provided to enable each user to be aware of the policies
governing any certificate that he may encounter. In
particular, a user should be able to establish how carefully
and thoroughly the CA authenticated owner identity of the
public key before certifying the association between the user
and the key.

   +    *Trusted Certificate Authority*. Digital signatures
are used to ensure sender authentication, nonrepudiation, and
message integrity. To trust these security services, the user
needs to be assured that the public key used to verify a
signature is actually the key of the person who signed the
transaction. To ensure that certificates are generated by and
obtained from trusted sources, mechanisms are needed to
prevent any user from creating false certificates that are
signed with the user's regular private key. Even though a
signature can be verified by employing the user's properly
certified public key, the false certificates must not be
accepted as legitimate. Then a pretender cannot create
signatures that will be accepted because they are verified
using keys obtained from the false certificates. Since the CA
performs user authentication at key certification time and is
responsible for keeping the user's name and public key
associated, each CA must be a trusted entity, at least to the
extent defined in the pertinent PCA policies. This implies the
provision of some security protection for each CA,
specifically the private key of the CA, so that the CA cannot
be modified or impersonated. Certification policies can
specify the security measures a particular CA undertakes.
Users must determine whether the CA is sufficiently
trustworthy for their applications. The basic trust rests in
the certification policies and security mechanism established
for the infrastructure

   +    *User Affiliation*. To have a CA certify a public key,
a user must provide a unique name in addition to the public
key that is to be certified. That name usually contains the
user's organizational affiliation. It is possible, however,
that some private citizens may wish to have their keys
certified independently of any organization. Therefore,
provisions for certifying private citizens must also be made.

   +    *Privacy of User's Identity*. Some users may wish to
remain anonymous but still register with a CA. This may
require the establishment of certification agencies that would
register users requesting nondisclosure of their
identification information. Alternatively, policy choices in
different segments of the infrastructure could include or
exclude anonymous certificates.

   +    *Multiple Certificates*. In some instances a user may
have several certificates, each issued by a different CA. This
situation may occur if a user belongs to more than one
organization and needs a certificate from each organization or
if a user has a certificate as an employee and another
certificate as a residential user. If the naming convention
includes a user's organizational affiliation in the person's
unique name, then a user can have several unique names with a
different certificate associated with each. Multiple
certificates assigned to a single unique name may be used to
simplify recovery from CA private-key compromise. The
infrastructure may have to handle multiple certificates for a
single user.

   +    *Certification Revocation Lists*. When a private key
is known to be compromised or even when its compromise is only
suspected, it must be replaced immediately. The certificate
containing the associated public key must be revoked
immediately. To inform users of such a compromised key, thus
allowing them to identify and reject possibly fraudulent
transactions, the certificate is placed on a Certificate
Revocation List (CRL). Placing a certificate on a CRL can also
be used to announce the severing of a relationship between a
signer and the organization with which he or she was once
associated.

   +    *Services of CA*. CAs will need to certify public
keys, create certificates, distribute certificates, generate
CRLs, and distribute CRLs. Distribution of certificates and of
CRLs will be accomplished by depositing them with a generally
available directory service.

   +    *Security and Legal Efficacy*. There is an inherent
linkage between security and legal efficacy. The security of
electronic messages and records is not only a business
requirement, but also an underlying legal requirement. This
linkage determines what is sufficiently secure by considering
what presumptions apply to the particular message's or
document's purpose(s) and by considering the risks it
confronts. Legal requirements should clarify reasonable
security procedures without sacrificing needed flexibility.
The question is not whether to have or not to have security,
but rather whether the implemented security mechanisms provide
the degree of security offered by the digital signatures. The
answer rests squarely on the strength of the infrastructure's
security mechanisms.

   +    *Liability*. The extent of the infrastructure's
liability must be founded on a balance between the interest of
the government, which would limit it, and of the private
sector, which would expand it. Bringing suit must be
allowable, but there must also be a reasonable limit on the
extent of the infrastructure's liability. Different levels of
liability limitations can be offered. For a price, users might
even be allowed to tailor the extent of protection to their
needs.

   In committee discussions, it was noted that the liability
of those providing authentication services is a critical
issue. When the provider of authentication services is a
business with which one is interacting for other purposes
(e.g., to buy something), that business will generally have to
accept liability for the interaction. Thus, if it wrongly
certifies that Joe is Jack, and if Joe then steals money out
of Jack's account, the bank that authenticated the transaction
is liable. Likewise, third-party authentication services whose
job it is to provide authentication services, but nothing
more, would or should accept liability. Appropriate insurance
requirements and a legislative framework might be necessary to
regulate such services to ensure that the adhere to good
practice.

   As an agency of the federal government, the infrastructure
may be considered to have sovereign immunity. Such immunity
would imply that the infrastructure and its managers cannot be
sued for any losses resulting from their actions or from their
inaction. Although such a status may be attractive, it
undermines the usefulness of the certification infrastructure.
Without reasonable assurances that potential losses due to
malfeasance will be recoverable, a typical nongovernment user
will shy away from relying on the public-key infrastructure.
Any set of laws and regulations must strike a balance between
protection of the government from excessive claims and
blocking users from any chance of reimbursement. The following
items summarize what may be considered reasonable limits on
the extent of liability to which a CA at any level and
ultimately the public-key infrastructure as a whole should be
exposed.

   -- A CA has no liability associated with the loss of the
   private keys of its clients or with their generating weak
   private keys.

   -- A key-generation facility has no liability associated
   with the compromise of the private keys it produces unless
   it can be proved that the documented policies and
   procedures relevant to the facility were not followed
   during the key-generation process, resulting in a weak
   private key that is more susceptible to compromise or the
   actual revelation of a private key.

   -- A key-generation facility has limited liability for the
   compromise of a private key during the key distribution
   process if the documented policies and procedures relevant
   to the facility are not followed, resulting in the
   revelation of the private key.

   -- A CA has no liability associated with forged signatures
   unless the forgery results because the documented policies
   and procedures relevant to the CA were not followed.

   -- A CA has no liability associated with the wrongful
   binding of an individual's identity with an associated
   public key unless it can be proved that the documented
   policies and procedures for identification and
   authentication relevant to the CA were not followed.

   -- A CA has limited liability for not revoking certificates
   according to its revocation policy.

   -- A CA has limited liability for revoking a certificate
   for a reason not specified in its revocation policy.

   -- A CA has limited liability if, despite its having
   followed published policies and procedures, a certificate
   in the database is modified or deleted.

   +    *Liability Policy*. The extent of the liability in the
above situations is conceivably a part of the policy under
which a CA or key-generation facility operates. The policy
must distinguish between direct liability on the one hand and
indirect and consequential damages on the other.

----------

   (1)  Shimshon Berkovits et al. (MITRE Corporation), *Public
Key Infrastructure Study: Final Report*, National Institute of
Standards and Technology, Gaithersburg, Md., April 1994.

____________________________________________________________

[End Appendix H]





