Read more than 3,000 books online FREE! More than 900 PDFs now available for sale HOME ABOUT NAP CONTACT NAP HELP NEW RELEASES ORDERING INFO Items in cart [0] TRY OUR SPECIAL DISCOVERY ENGINE: Questions? Call 888-624-8373

Cryptography's Role in Securing the Information Society (1996) Computer Science and Telecommunications Board (CSTB)

Find More Like This Book Research Dashboard NEW! BUY This Book

CHAPTER SELECTOR: Openbook Linked Table of Contents Front Matter, pp. i-xxxii Executive Summary, pp. 1-14 A Road Map Through This Report, pp. 15-16 Part I - Framing the Policy Issues, pp. 17-18 Growing Vulnerability in the Information Age, pp. 19-50 Cryptography: Roles, Market, and Infrastructure, pp. 51-78 Needs for Access to Encrypted Information, pp. 79-110 Part II - Policy Instruments, pp. 111-112 Export Controls, pp. 113-166 Escrowed Encryption and Related Issues, pp. 167-215 Other Dimensions of National Cryptography Policy, pp. 216-246 Part III - Policy Options, Findings, and Recommendations, pp. 247-248 Policy Options for the Future, pp. 249-292 Syntehsis, Findings, and Recommendations, pp. 293-340 A - Contributors to the NRC Project on National Cryptographi..., pp. 341-352 B - Glossary, pp. 353-363 C - A Brief Primer on Cryptography, pp. 364-395 D - An Overview of Electronic Surveillance: History and Curr..., pp. 396-413 E - A Brief History of Cryptography Policy, pp. 414-420 F - A Brief Primer on Intelligence, pp. 421-429 G - The International Scope of Cryptography Policy, pp. 430-449 H - Summary of Important Requirements for a Public-Key Infra..., pp. 450-454 I - Industry-Specific Dimensions of Security, pp. 455-468 J - Examples of Risks Posed by Unprotected Information, pp. 469-473 K - Cryptographic Applications Programming Interfaces, pp. 474-476 L - Other Looming Issues Related to Cryptography Policy, pp. 477-484 M - Federal Information Processing Standards, pp. 485-488 N - Laws, Regulations, and Documents Relevant to Cryptograph..., pp. 489-676 Index, pp. 677-688
GO TO PAGE:	TABLE OF CONTENTS PAGE 450 PRINTABLE PDF PAGE CHAPTER   PAGE	SEARCH THIS BOOK:

CHAPTER SELECTOR: Openbook Linked Table of Contents Front Matter, pp. i-xxxii Executive Summary, pp. 1-14 A Road Map Through This Report, pp. 15-16 Part I - Framing the Policy Issues, pp. 17-18 Growing Vulnerability in the Information Age, pp. 19-50 Cryptography: Roles, Market, and Infrastructure, pp. 51-78 Needs for Access to Encrypted Information, pp. 79-110 Part II - Policy Instruments, pp. 111-112 Export Controls, pp. 113-166 Escrowed Encryption and Related Issues, pp. 167-215 Other Dimensions of National Cryptography Policy, pp. 216-246 Part III - Policy Options, Findings, and Recommendations, pp. 247-248 Policy Options for the Future, pp. 249-292 Syntehsis, Findings, and Recommendations, pp. 293-340 A - Contributors to the NRC Project on National Cryptographi..., pp. 341-352 B - Glossary, pp. 353-363 C - A Brief Primer on Cryptography, pp. 364-395 D - An Overview of Electronic Surveillance: History and Curr..., pp. 396-413 E - A Brief History of Cryptography Policy, pp. 414-420 F - A Brief Primer on Intelligence, pp. 421-429 G - The International Scope of Cryptography Policy, pp. 430-449 H - Summary of Important Requirements for a Public-Key Infra..., pp. 450-454 I - Industry-Specific Dimensions of Security, pp. 455-468 J - Examples of Risks Posed by Unprotected Information, pp. 469-473 K - Cryptographic Applications Programming Interfaces, pp. 474-476 L - Other Looming Issues Related to Cryptography Policy, pp. 477-484 M - Federal Information Processing Standards, pp. 485-488 N - Laws, Regulations, and Documents Relevant to Cryptograph..., pp. 489-676 Index, pp. 677-688 GO TO PAGE: TABLE OF CONTENTS PAGE 450 PRINTABLE PDF PAGE CHAPTER   PAGE   SEARCH THIS BOOK:

The Open Book page image presentation framework is not designed to replace printed books. Rather, it is a free, browsable, nonproprietary, fully and deeply searchable version of the publication which we can inexpensively and quickly produce to make the material available worldwide.

For most effective printing, use the "printable PDF page" link available on each OpenBook page's tool block. The 300 x 150 dpi PDF linked to it is printable on your local printer.

More information on the Open Book is available.

[ Top of Page ] [ Home ] [ Contact Us ] [ Help ] [ The National Academies Home ]

Copyright © 2005. National Academy of Sciences. All rights reserved. 500 Fifth St. N.W., Washington, D.C. 20001. Terms of Use and Privacy Statement

Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 450
Page 450 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 appendixbriefly 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 1 Shimshon Berkovits et al. (MITRE Corporation), Public Key Infrastructure Study: Final Report, National Institute of Standards and Technology, Gaithersburg, Md., April 1994.

OCR for page 451
Page 451 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 that 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 mechanisms 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.

OCR for page 452
Page 452 • 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

OCR for page 453
Page 453 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 they 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

OCR for page 454
Page 454 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 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.

Representative terms from entire chapter:

associated public key, weak private key, public key, private key, weak private keys, limited liability, liability associated, authentication services, documented policies, private keys, security mechanisms, unique name, procedures relevant, key certification, weak private, associated public, certification policies, false certificates, organizational affiliation, infrastructure based, revocation policy, public keys, regular private, certified public, key associated, private citizens, key infrastructure, certify public, security procedures, key distribution